Method and apparatus for managing physician referrals

ABSTRACT

Method and apparatus for managing the physician referral process, whereby a referring physician (e.g., a primary care provider) refers a patient to another physician (e.g., a specialist) for a particular medical procedure, analysis or care. An aggregator provides systems and methods available to physicians and their administrative staff (herein collectively referred to as physicians or doctors) to: book appointments on behalf of their patients online through a doctor directory and calendar function; filter available doctors by specialty, subspecialty, procedure, insurance participation and/or hospital network; transfer a patient&#39;s personal information, medical history and pre-selected insurance forms from one doctor&#39;s office to another&#39;s, electronically; transfer and upload relevant forms and paperwork via fax from one doctor&#39;s office to another; track referrals historically (over time) on a by-doctor or by-patient basis; facilitate referrals to and from doctors in a certain network or group.

FIELD OF THE INVENTION

The present invention relates to a method and apparatus for managing thephysician referral process, whereby a referring physician (e.g., aprimary care provider) refers a patient to another physician (e.g., aspecialist) for a particular medical procedure, analysis or care.

BACKGROUND

Comprehensive medical care often requires a patient to visit more thanjust one doctor. While many patients have an established andlong-standing relationship with their primary care provider, they aregenerally unfamiliar with more specialized doctors until medicalcircumstances necessitate a referral to one. Upon receiving a referral,the patient is usually the one left to arrange an actual appointmentwith the specialist. There is little transparency in this process, andunder unfavorable circumstances a patient may find himself/herselfreferred to a doctor with little to no near-term availability, or adoctor who no longer accepts his or her insurance. These hurdles maycause delays in medical care, and in some cases even dissuade patientsfrom complying with their primary care provider's recommendation to seekadditional medical care from a specialist.

One proposed solution is for the primary care provider to use a remotedesktop session with the secondary care provider's office to make anappointment while the patient is in communication (e.g., on the phone)with the primary care provider. This is not a desirable solutionbecause:

-   -   a) the primary care provider needs to have remote desktop access        to the secondary care provider's office, which is a security        risk;    -   b) the primary care provider's phone agent needs to be trained        on how to use the scheduling software in the secondary care        office correctly, and since there are potentially many different        offices and scheduling systems, this is not feasible nor        scalable;    -   c) the primary care agent attempting to schedule the appointment        does not know the rules about when appointments can be made with        the secondary care provider, so often the appointment is not        made.

The problems do not end with booking the referral appointment. There isno protocol for rescheduling missed or canceled appointments, sharing ofpatient information between the primary and secondary care offices,follow-up appointments with the primary care provider, etc.; each ofthese additional steps require someone to reestablish communicationbetween one or more of the patient's primary care physician and thesecondary care physician. The inefficiencies in managing this processare a drain on both the primary and secondary physicians. The patient,who has the least amount of medical knowledge and often an inability toanticipate or articulate the critical nature or timing of the referral,is left calling one or both offices and communicating with areceptionist who cannot independently determine what the next step inthe process should be, without again involving either the primary orsecondary care physicians.

The issues described above have been long-standing problems for bothphysicians and patients, and substantially interfere with the ability toprovide appropriate and cost effective medical care.

SUMMARY OF THE INVENTION

In one or more embodiments of the invention, an apparatus and method areprovided that allows doctors and their administrative staff to managethe process of physician referrals, whereby a patient is referred fromone physician (the referring physician) to another physician (thereferred-to or receiving physician) for a particular medical procedure,or analysis or care.

In one embodiment, an aggregator provides systems and methods availableto physicians and their administrative staff (herein collectivelyreferred to as physicians or doctors) to:

-   -   book appointments on behalf of their patients online through a        doctor directory and calendar function;    -   filter available doctors by specialty, subspecialty, procedure,        insurance participation and/or hospital network;    -   transfer a patient's personal information, medical history and        pre-selected insurance forms from one doctor's office to        another's, electronically;    -   transfer and upload relevant forms and paperwork via fax from        one doctor's office to another;    -   track referrals historically (over time) on a by-doctor or        by-patient basis;    -   facilitate referrals to and from doctors in a certain network or        group.

These new features bring significant benefits to doctors and hospitals,increasing the efficiency of their workflows and improving patient carewhile reducing administrative costs, patient “leakage” (referralsoutside the referring physician's network of providers), and theprobability of errors in patient care.

In further embodiments, there are provided systems and methods foreliminating inefficiencies in the sharing of patient information,enabling, for example, the referring doctor to track a patient'sprogress after treatment by a specialist, thereby eliminatinguncertainty and allowing more effective treatment in their next meeting.

In a further embodiment, systems and methods are provided for reducingpatient non-compliance (e.g., failure to book or attend a scheduledappointment) with the physician referral process by establishingcommunication channels with the patient and the referred-to physician.

In a further embodiment, systems and methods are provided for reviewinga patient's progress after a referral appointment, by facilitatingcommunications about the patient between the referring physician and thereferred-to physician.

In a further embodiment, systems and method are provided for reviewingand reporting the results of one or more appointment referrals, enablingthe referring physician to analyze the patient experience and/or qualityof patient care, physician communication and history of (e.g.,willingness and ability to accept) referral appointments by thereferred-to physician.

In a further embodiment, systems and methods are provided forfacilitating referrals to in-network or otherwise affiliated physicians.

In a further embodiment, systems and methods are provided for ensuringpatient care after a hospital discharge.

In a further embodiment, systems and methods are provided for managinghospital emergency room capacity, including referring select patients toavailable primary care providers with available appointments to reducethe unnecessary use/expense of emergency room facilities.

In a further embodiment, systems and methods are provided for ensuringproper post emergency room care, enabling emergency room discharge staffto make appointments with qualified physicians to provide post-dischargecare.

These and other embodiments of the invention are further described inthe following detailed description and accompanying drawings.

According to one embodiment of the invention, an online physicianreferral apparatus is provided comprising:

-   -   a computer apparatus for managing and storing a central managed        database of physician profiles and scheduling information for        physicians belonging to different provider groups, the database        containing both physician profile data (PPD) and available        appointment times for the physicians, wherein the PPD includes        the physician's specialty, location and insurance or payment        information; and    -   an online portal, accessible by computer to referring physicians        over a network, for computer implemented filtering of the PPD        and available appointment times on behalf of a patient of the        referring physician, the portal including a user interface        enabling the referring physician to select and book on-line a        referral appointment on behalf of the patient with one of the        physicians based on a filtered combination of the available        appointment times and PPD.

In one embodiment,

-   -   the portal comprises a Web site and the user interface is        accessible via a Web browser for filtering and selecting the one        physician for the referral appointment.

In one embodiment,

-   -   the PPD further includes one or more of an affiliation of the        physician with a provider group, insurance carrier, insurance        plan, and procedures performed.

In one embodiment,

-   -   the database further includes the selected booked appointments        and patient records relevant to such appointments.

In one embodiment,

-   -   the database includes an identifier for correlating patient and        patient records.

According to another embodiment of the invention, a method for onlinebooking of physician referrals is provided comprising:

-   -   a referring physician accessing an online portal to a central        managed database of physician profile data (PPD) and available        appointment times for physicians belonging to different provider        groups, the PPD including the physician's specialty, location        and insurance or payment information;    -   the referring physician performing the following steps via the        portal:        -   filtering the PPD and available appointment times on behalf            of a patient of the referring physician and selecting, on            behalf of the patient, a referral appointment with one of            the physicians based on a filtered combination of the            available appointment times and PPD;        -   entering identification information for the patient; and        -   booking the selected appointment for the identified patient.

In one embodiment, the PPD further includes one or more of anaffiliation of the physician with a provider group, insurance carrier,insurance plan, and procedures performed.

In one embodiment, the filtering step is based on specialty and locationand the portal displays a filtered listing of the physicians and theiravailable appointment times.

In one embodiment, in response to the filtering, the portal displays afiltered listing of the physicians including their respective name,specialty, location, and insurance or payment information.

In one embodiment, the referring physician further performs the step oftracking one or more selected appointments.

In one embodiment, the tracking is performed based on one or more of theselected physician and the patient.

In one embodiment, the method further comprises the step of thereferring physician transferring patient information to the selectedphysician.

In one embodiment, the method further comprises the step of the selectedphysician transferring patient information via the portal to thereferring physician.

In one embodiment, the method further comprises the step of thereferring physician reviewing on the portal a booking history ofselected appointments.

In one embodiment, the booking history can be filtered by the referringphysician based upon one or more of the patient, selected physician,specialty and date.

In one embodiment, the booking history comprises one or more of:

-   -   appointment status;    -   clinical information;    -   patient identification information;    -   selected physician;    -   appointment time;    -   appointment history; and    -   further actions regarding the patient.

In one embodiment, the method further comprises the step of thereferring physician establishing communication via the portal with oneor more of the patient and the selected physician.

In one embodiment, the communications include one or more of a reminderto the patient and providing patient information to the selectedphysician.

In one embodiment, the method further comprises the step of thereferring physician reviewing a history of the communications on theportal.

In one embodiment the method further comprises the steps of the portaldisplaying a description of the booked appointment and the referringphysician printing the displayed description and providing the printeddescription to the patient.

In one embodiment, the portal is a website.

In one embodiment, the patient information can be uploaded by thereferring physician to the portal.

In one embodiment, the patient information can be uploaded by theselected physician to the portal.

In one embodiment, a computer readable storage medium is provided withinstructions to one or a plurality of computers for execution of thedescribed methods.

According to another embodiment of the invention, a method for onlinebooking of physician referrals is provided comprising:

-   -   a referring physician accessing an online portal to a central        managed database of physician profile data (PPD) and available        appointment times for physicians belonging to different provider        groups, the PPD including the physician's specialty, location        and insurance or payment information;    -   the referring physician performing the following steps via the        portal:        -   filtering the PPD on behalf of a patient of the referring            physician to select, on behalf of the patient, one of the            physicians based on the PPD;        -   entering identification information for the patient; and        -   notifying the selected physician electronically to arrange            for a referral appointment.

In one embodiment, following the notification, the referring physiciantransfers patient information to the selected physician via the portal.

In one embodiment, the method further comprises the step of thereferring physician tracking one or more of the appointment and thepatient's progress via the portal.

According to another embodiment of the invention, a system for managingpatient referrals is provided comprising:

-   -   an online portal, accessible by computer to a referring        physician over a network, providing access to a central managed        database of physician profile data (PPD) and available        appointment times for physicians belonging to different provider        groups;    -   the portal including a user interface enabling the referring        physician to filter the

PPD and available appointment times and select, on behalf of a patientof the referring physician one of the physicians for a referralappointment;

-   -   the portal providing one or more communication channels for        communication between the referring physician and one or more of        the patient and the selected physician for:        -   initiating and tracking toward completion the referral            appointment of the patient with the selected physician; and        -   transferring of patient information.

According to another embodiment of the invention, a network basedscheduling system is provided, the system comprising:

-   -   an aggregator managed database containing information relevant        to referring physicians who periodically need to schedule        referral appointments with other physicians;    -   a set of parameters associated with each of a plurality of        physicians accepting referral appointments having available        appointment times;    -   a central controller managing a referral appointment schedule        for the aggregator, wherein the central controller operates via        a network to:        -   receive scheduling information via the network from the            physicians accepting referral appointments;        -   supply available appointment times via the network to the            referring physicians, with the supplied available            appointment times determined by input received from the            referring physician on behalf of a patient of the referring            physician;        -   wherein the controller supplies an available appointment            calendar via the network to the referring physician of the            available appointment times, and wherein the referring            physician can schedule an appointment via the network by            selecting a desired appointment time.

In one embodiment, the network is the Internet.

In one embodiment, the aggregator provides a Web portal accessible tothe physicians for receiving and supplying the scheduling andappointment times.

In one embodiment, the controller synchronizes the available appointmenttimes with the appointment calendars of the physicians acceptingreferral appointments.

In one embodiment, the controller supplies a real time master schedulevia the network.

In one embodiment, the controller operates via the network to supplytracking information relevant to the selected appointment.

In one embodiment, the tracking information includes one or more of:

-   -   patient contact information;    -   patient insurance information;    -   affiliation of the physician accepting referral appointments;    -   patient information supplied by the physician accepting referral        appointments;    -   patient information supplied by the referral physician;    -   patient clinical information;    -   appointment history information;    -   physician notes concerning the patient

In one embodiment, the selecting is based on at least one of thespecialty and procedures performed.

In one embodiment, the selecting is based on the specialty, location andinsurance or payment information.

In one embodiment, the selecting is based on the affiliation.

In one embodiment, the selecting is based on the insurance or paymentinformation and at least one of the specialty and procedures performed.

In one embodiment, the referring physician selects one of the displayedavailable appointment times.

In one embodiment, the filtering step is based on specialty, location,and type of insurance or payment information and the portal displays afiltered listing of the physicians and their available appointmenttimes.

In one embodiment, filtering step is based on at least one of specialty,location, affiliation, procedures performed, and insurance or paymentinformation and the portal displays a filtered listing of the physiciansand their available appointment times.

In one embodiment, the referring physician enters insurance or paymentinformation for the patient and the filtering step includes filteringbased upon a match of the physician's insurance or payment informationand the patient's insurance or payment information.

In one embodiment, the insurance information comprises one or more of aninsurance carrier and an insurance plan.

In one embodiment, the referring physician enters a reason for anappointment, and the filtering step includes filtering based upon theentered reason.

In one embodiment, the patient identification information comprises oneor more of the patient's email address, phone number, and name.

In one embodiment, the referring physician enters patient identificationinformation for a new patient not existing in the database.

In one embodiment, the referring physician enters patient identificationinformation for an existing patient in the database.

In one embodiment, the method further comprises the step of registeringthe referring physician to allow access to the portal.

In one embodiment, access to the portal is limited to referringphysicians previously registered with the portal.

In one embodiment, the PPD includes an affiliation of the physician witha provider group and the tracking is performed based on the affiliationof the physician.

In one embodiment, the patient information includes one or more ofclinical information, contact information, physician notes and insuranceforms.

In one embodiment, the booking history includes links to additionalinformation concerning one or more of the appointment, the selectedphysician and the patient.

In one embodiment, the links include one or more of insurance forms,patient clinical information, medical history, physician notes andappointment history.

In one embodiment, the communication comprises sending an electroniccommunication to the patient regarding the booked appointment.

In one embodiment, the central managed database is synchronized with oneor more appointment calendars of the different provider groups.

In one embodiment, the booked appointment is synchronized automaticallywith a scheduling calendar of the selected physician.

In one embodiment, the physicians are not required to be registered withthe portal.

In one embodiment, the central managed database further includes patientinformation comprising one or more of patient clinical information,patient contact information, patient insurance form, patient testresult, and appointment history.

In one embodiment, the referring physician is notified of a missedappointment.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a schematic representation of an exemplary communicationsnetwork for implementing various embodiments of the present invention;

FIG. 2 is a block diagram of an exemplary computer on which the softwareproduct(s) of the present invention may be executed;

FIG. 3 is one example of a webpage from an aggregator's website enablinga referring physician to identify potential specialists for a referralappointment according to one embodiment of the invention;

FIG. 4 is one example of an aggregator's webpage for entering patientinsurance or payment information;

FIG. 5 is one example of an aggregator's webpage for entering patientinformation;

FIG. 6 is one example of an aggregator's webpage for confirming thebooking of a referral appointment;

FIG. 7 is one example of an aggregator's webpage for printingconfirmation of the referral booking;

FIG. 8 is one example of an aggregator's webpage allowing a referringphysician to review a booking history of referral appointments;

FIG. 9 is one example of a more detailed webpage link to a specificpatient in the booking history of FIG. 8;

FIG. 10 is another example of a linked webpage from the booking historyof FIG. 8;

FIG. 11 is a schematic illustration of one method and apparatus forbooking referral appointments in which both the referring physician andspecialist utilize the Referral Cockpit;

FIG. 12 is a schematic illustration of a method and apparatus accordingto one embodiment of the invention in which the referring physicianpostpones selection of a specific appointment time;

FIG. 13 is a schematic illustration of a method and apparatus accordingto one embodiment of the invention in which a referring physician booksa referral appointment outside the Referral Cockpit system;

FIG. 14 is a schematic illustration of a method and apparatus accordingto another embodiment of the invention in which the referring physicianbooks an appointment outside the Referral Cockpit system;

FIG. 15 is a schematic illustration of a method and apparatus accordingto another embodiment of the invention in which an emergency roomadministrator books a referral appointment;

FIG. 16 is a schematic illustration of a method and apparatus accordingto another embodiment of the invention in which patient records aretransferred via the aggregator;

FIG. 17 is one example of a database structure according to one methodand apparatus of the invention in which the aggregator database usesstored doctor and patient data to enable the booking of a referralappointment; and

FIG. 18 shows one example of database records according to oneembodiment of an apparatus and method of the invention containing storedreferral appointment information.

DETAILED DESCRIPTION Network Communications

Apparatus and methods are described herein for improving the patientreferral process which enables online booking of healthcare appointmentson a centralized service provider's (aggregator's) website. For thesepurposes, network based communications are required between one or moreof the aggregator, physician practice groups, patients, hospitals andinsurers. The block diagrams of one such communication system isillustrated in FIG. 1 and is meant to be representative only. Suitablehardware, communication protocols and software languages forimplementing the systems and methods of various embodiments of theinvention are readily known to those who are skilled in the art and anydiscussion herein is not meant to limit the scope of the invention.

FIG. 1 illustrates schematically network communications among variousserver computers 4 a, 4 b, 4 c, and 4 d and client computers 5 a showncoupled together via a network or cloud 6 (e.g., the Internet) tocommunicate with one another using standard communication protocols,such as TCP/IP. The servers can be any type of server, including but notlimited to a Windows, Unix, Linux and/or Apple servers. Each server mayhave an attached data storage system 3 a, 3 b, 3 c and 3 d for storingsoftware applications and data.

In accordance with one embodiment of the invention, the network of FIG.1 allows communications between a centralized service provider(aggregator), multiple healthcare practitioner practice groups, multiplehospitals, multiple insurers, and multiple patients. The aggregator'sserver provides a network based service to the practitioner groups,hospitals, insurers, and patients, e.g. an aggregator's server 4 aprovides a web-based data processing service and interface to each ofthe physician or patient computers 5 a, practice group servers 4 b,hospital servers 4 c, and insurance provider servers 4 d, and can alsocommunicate electronically via email with each of these computers andservers. The aggregator's server also communicates (e.g. web-based) witheach of the practice groups, hospitals and insurers via their respectiveservers for retrieving data such as available appointment times andother information for each of the practice groups, hospitals andinsurers in order to enable online booking and confirmation ofappointments on multiple websites. In alternative embodiments, theaggregator's service is provided to one or more practice groups, one ormore hospitals, and/or one or more insurance provider(s). For ease ofdescription, a first embodiment will refer to practice groups, it beingunderstood that the services can similarly be provided to otherhealthcare provider groups.

FIG. 2 is a block diagram of one server 4 which includes a processor 8,memory 9, data storage 10, disk drive 11, keyboard/mouse 12, computerdisplay 13 and network interface 14. The components are coupled togetherand communicate via a system bus 16. Various software modules of thepresent invention can be loaded into data storage and during operationare transferred into memory (e.g. RAM) for execution by the processor. Auser may manipulate the software and enter commands to the server usingthe keyboard/mouse. The input/output may be viewed on the displayscreen. The network interface couples the server to the Internet orwhatever type of network is used to connect the server with the othercomputers and servers of the respective practice groups, patients,hospitals, insurers and aggregator. Further, the server may communicatewith a storage array or storage network (e.g. SAN) if there is a need toaccess large amounts of data. A database of patient records, practicegroup (practitioner) records, and associated scheduling records may beimplemented as a relational database and search engine with, forexample, Microsoft's Active Server Page Technology, SQL ServerTechnology, Database Artisan Software, or database products from OracleCorp., Redwood Shores, Calif.

The software described herein may be implemented as various modules,e.g. a web module, a database module, an email module, a facsimilemodule, and standard application programming interfaces (APIs). The webmodule may include a set of templates and icons to enable the creationof web pages. It may include other tools to allow one to create browserfriendly websites. These tools enable the creation of dynamic hypertextweb pages to be accessed by the practice groups, hospitals, insurers,patients and aggregator.

The database module may include a relational database and search engine.The records, fields, search queries and other features of the databaseare described below and suitable alternatives will be apparent topersons who are skilled in the art.

As used herein, database is meant to include any of various types ofdata repositories and processes for indexing, searching, storage andretrieval from such repositories.

The email module allows emails to be sent to/from patients, practicegroups, hospitals, insurers and the aggregator via the respectiveserver/computer. The emails can be sent manually by a person operatingthe server and can be automatically generated by the server. Forexample, the email module can be configured to automatically query thedatabase module and send email messages to entities identified in thedatabase module.

The software may include standard APIs so data and other information canbe exchanged with other software systems.

Each practice group server may include the group's own practicemanagement software and any other database of information used by thepractitioners in that group. As described below, the aggregator mayinstall software on the practice group's server for uploading availableappointment times to the aggregator's database and otherwise automatingand synchronizing the appointment calendars of the practice group andthe aggregator. The relevant appointment booking information may bestored on one or both of the aggregator and practice group servers anddata storage systems. Similarly, the aggregator may install software ona hospital's server and/or insurer's server for the same or similarpurposes (e.g., exchange of profile information and/or appointmentscheduling information).

The database maintained by the aggregator may include records ofpractitioner profile information and booking information for thepractice groups and their respective practitioners, the hospitals andtheir affiliated practitioners, the insurance providers and theirparticipating practitioners, and each patient who establishes an accountwith the aggregator. These records will be described further below invarious embodiments.

Various systems and methods for aggregating available appointment timesfor multiple practitioner groups, including search and displayalgorithms are described in the following co-pending and commonly ownedUS Patent Applications:

-   -   U.S. Ser. No. 12/210,664 filed 15 Sep. 2008 entitled:        CENTRALIZED MARKETPLACE FOR HEALTHCARE APPOINTMENTS ACROSS        PRACTICE GROUPS;    -   U.S. Ser. No. 12/210,690 filed 15 Sep. 2008 entitled: CONSUMER        PORTAL FOR HEALTHCARE APPOINTMENTS ACROSS PRACTICE GROUPS;    -   U.S. Ser. No. 12/210,765 filed 15 Sep. 2008 entitled: DATA        SYNCHRONIZATION FOR BOOKING OF HEALTHCARE APPOINTMENTS ACROSS        PRACTICE GROUPS; and    -   U.S. Ser. No. 12/210,716 filed 15 Sep. 2008 entitled: PATIENT        VERIFICATION FOR BOOKING OF HEALTHCARE APPOINTMENTS ACROSS        PRACTICE GROUPS.    -   U.S. Ser. No. 12/722,728 filed 12 Mar. 2010 entitled: METHOD AND        APPARATUS FOR MANAGING PHYSICIAN PROFILE AND HEALTHCARE        APPOINTMENT SERVICES.

Physicians and Practice Groups

In various embodiments of the invention disclosed herein, the term“physician” or “doctor” refers to a physician administering patientcare, as well as to those members of his staff responsible formaintaining the physician's calendar and/or patient records. Though theterm is used interchangeably, it should be understood that in theexemplary figures and accompanying text, each function is beingperformed by one or more persons that perform such activities in aparticular doctor's office on behalf of a physician.

The term “specialist” is applied to a physician administering secondarycare to a patient after a referral from a referring physician, and isalso applied to other members of his staff in the same manner as is donefor a physician. It may be possible for any given physician to in onesituation be a specialist (receiving a patient via referral), and inanother be a primary care physician (referring a patient to anotherphysician for specialized care).

Accordingly, in cases where primary care physicians and specialists workin integrated facilities and/or share administrative staff, the samestaff member may process both the referral and its receipt. However,even if this were the case, there would still be authentication requiredon both ends of the referral process, meaning that there would still beeffectively two users (one representing the referring physician, one thereceiving specialist) involved, even if there was only one actual personresponsible.

Further a “provider group” or “practice group” may be any entity linkinga group of doctors through shared facilities, services, or referralagreements. This can include but should not be limited to integratedmulti-facility hospitals, insurance networks, medical groups, andmulti-doctor practices.

Online Booking of Referral Appointments

According to one embodiment of the invention, a portal referred toherein as a Referral Cockpit enables a referring (e.g., primary care)provider's office to initiate a search for and then select among acustomized list of doctors based on a desired patient procedure,specialty, accepted insurances, affiliation with provider systems,and/or a number of further criteria (geographic location, gender, etc.).The office can then choose from available time slots in real time, andbook a referral appointment online. This makes it far easier to ensurethat the patient can see a specialist in close proximity and timelyfashion. It also eliminates the possibility that the patient may foregonecessary care due to the inconvenience of obtaining an appointment.

Each practice has the ability to edit their physician's displayedavailability, accepted procedures, and accepted insurance plans. Thesedata are stored on an aggregator database and made available to othermedical professionals with access to the system. For many commonpractice management systems, availability can also be synchronizedautomatically with the doctor's existing calendar.

If a practice chooses not to display its availability in real time (oris not technologically capable of having someone maintain its calendar),or a patient does not yet want to decide on a time, the referringpractice can still make a tentative appointment. A notification is thensent electronically to both the patient and the receiving (referred-to)practice. The patient's data now becomes accessible to the receivingpractice, offering the opportunity to send reminders and arrange for theappointment at a later time.

Via the “Find Doctor” function (described below), a doctor or practicemanager can input a patient's desired procedure, location, insuranceprovider and plan. These parameters serve to filter the view of thedatabase provided to the referring party, and thus create a view ofavailable appointments.

An example of an apparatus and method for online booking of referralappointments will now be described with respect to FIGS. 3-10.

FIG. 3 is an example of a webpage 20 from an aggregator's website whichenables a referring physician to filter profile data stored in theaggregator's central managed database for selecting an acceptablephysician for the referral appointment.

The webpage entitled “Find Doctor” includes eight filtering (input)windows 21-28 prompting the referring physician to enter or select froma pull down menu, for the following items: doctor or practice 21,location (zip code, neighborhood, or city) 22, specialty 23,sub-specialty 24, reason for visit 25, insurance company 26, insuranceplan 27, and a checkbox to select “only show doctor's with availability”28. The referring physician enters the appropriate information and thenclicks the search button 29, initiating the search of the aggregator'sdatabase based on the entered filtering information. Not all items(fields) are required for the search, rather the referring physician canpick among the windows based upon his or her knowledge of the specificpatient, medical condition, desire to select a physician within anaffiliated network, and/or location. As one example, the referringphysician enters the specialty 23 and location 22. Below the filteringwindows 21-28 is a results window 30, containing a list of potentialreceiving physicians that satisfy the filtering criteria. In thisexample, there is a separate row of information for each receivingphysician; FIG. 3 shows the initial three rows 31, 32, 33 for the firstthree physicians. Each row includes a first column containing a numberedmap marker 34 which also appears in another window 43 located on theupper right hand corner of the page, the window 43 being a geographicaldisplay (street map) showing the location of the physician's office bythe same numbered marker. If the physician has additional practicelocations, this is indicated by a link 42 (as shown for the physician inthe second row), wherein clicking on the link 42 will identify anddisplay additional map marker numbers, with corresponding markers on thegeographical display 43. Next to each map number 34, proceeding inserial order across the page, there is provided (where available) aphoto of the physician 35 and name and contact information for thephysician 36; the information 36 may include a link for accessingadditional profile information concerning the physician. In the next rowthere is a link 37 which prompts the user to enter the patient insuranceinformation at the top of the page (windows 26, 27), if not alreadyprovided. Next is a grid display 38 of available appointment times forthis physician. The grid includes column headings across the top withdesignations 39 for various days of the week, and an advance button toselect subsequent weeks. Below each day of the week, there areindividual links 40 for each available appointment time. This enablesthe referring physician to simply click on an appointment time link 40,to select an appointment on behalf of the patient. Alternatively, if aphysician does not wish to select an appointment time now, there is analternative process (link 41) enabling the patient to select anappointment time at a later date, as discussed further below.

Assuming the referring physician has selected an appointment time on theweb page of FIG. 3, the selected appointment time for the selectedphysician is then processed by the aggregator's software and theaggregator's website displays web page 50 shown in FIG. 4. In the lefthand box labeled insurance 51, the referring physician is now promptedto enter in the first filter window 52 a reason for the patient's visit,which may be selected from a pull down menu, and to confirm thepatient's insurance details, namely whether the patient is payinghimself 53, whether the patient has health insurance 54, entering thename of the insurance carrier 55, and entering the name of the insuranceplan 56. The referring physician then hits the button 57 to confirm theentered information. On the right hand side of this page 50, the displayincludes the referred-to physician identification information 58, thetime and date of the selected appointment 59, the location of theappointment 60 and a geographical display 61 with a map marker showingthe location of the appointment.

Once the referring physician clicks the confirmation button 57 in FIG.4, the entered information is processed by the aggregator's software andthe aggregator's website returns a web page 70 shown in FIG. 5. Thispage, entitled Patient Details, includes on the left hand side a window71 for entry of patient identification information. There are twooptions, either the referring physician enters identifying informationfor the patient in the upper portion 72, to determine if the patient ispreviously included in the aggregator database, or else the referringphysician creates a record for a new patient not previously existing inthe database, in the lower portion 79. Assuming the patient alreadyexists in the database, in this example he can be located either byentering his email address in window 73 and clicking the search button74, or alternatively entering his phone number in window 75 and his lastname in window 76 and clicking the search button 77. If no patient isfound with the specified email, the referring physician will be sonotified at 78.

If the referring physician needs to create a new patient record, thereferring physician then enters the following information in thedesignated boxes, the required information being designated with anasterisk: email address in window 80, phone number in window 81, whetherthe phone number is a cell phone in window 82, patient first name 83,patient last name 84, patient zip code 85, patient gender 86, andpatient date of birth 87.

The referring physician then clicks the next button 88 and theaggregator's software processes the entered information. Meanwhile, onthe right hand side of the page 70, there is again shown, similar to theright hand portion of FIG. 4, the same physician identification 58, timeand date of the appointment 59, location of the appointment 60, andgeographical display 61. In addition, there is shown in FIG. 5 thepatient insurance information 89 and reason for the visit 90.

Once the referring physician clicks one of buttons 74, 77 or 88 on webpage 70, the process accepts the entered information and returns a nextweb page 100 shown in FIG. 6. This page, entitled “Confirm Booking”,includes on the left hand side a window 101 which confirms the identityof the patient 102 and prompts the referring physician to establish acommunication channel with one or more of the patient 103 andreferred-to physician 106. Window 101 includes the patient's emailaddress, to which an email confirmation of the appointment will be sent104. If the referring physician wishes to also send a text reminder tothe patient, he so indicates this in input box 105. The referringphysician can also establish a communication channel 106 with theselected (referred-to) physician. The referring physician may enternotes concerning the patient and/or appointment in the entry window 107.The referring physician may click a link 108 to send a pre-completedreferral form specific to the patient and his insurance company, to thereferred-to physician. The referring physician may also elect to havefiles sent to the referred-to physician, as indicated in window 109.Each of the selected files 110 is listed in a box, and a removal button111 is provided in the event the referring physician elects to not sendthe file. Entry window 112 enables a physician to locate an additionalfile and attached that file 113 to the transmission. Finally, thereferring physician clicks the book it button 114, whereby the selectedcommunications will be sent to the patient and referred-to physicianrespectively. Web page 100 also displays the same physician/appointmentinformation 58-61 and 89-90 as the prior web page 70.

After electing to book the appointment by clicking button 114 on webpage 100, the process books the appointment and returns a web page 120with a booking receipt. The booking receipt includes on the left-handside a window 121 confirming the details of the appointment, includingthe same information 58-60 and 89-90 provided in the prior web pages. Inaddition, the booking receipt indicates whether a text reminder will besent to the patient at 122, and includes any notes 123 entered by thereferring physician. The receipt indicates that a confirmation email hasbeen sent to the patient's email address at 125. The referring physiciannow has the option to print the booking receipt and give a copy to thepatient, by clicking the print button 124. The booking receipt furtherprovides the patient with contact information for the aggregator,enabling the patient to contact the aggregator if the patient wishes tochange or cancel the appointment. The referring physician may nowproceed to schedule a new appointment, by clicking the new appointmentbutton 127.

Transfer of Patient Records

Over the course of a multi-doctor treatment process, a patient's medicalrecords must often be transferred between several offices. Each of thesetransfers carries with it the possibility of document loss, and thefrequent use of physical (paper) patient records only serves to increasethis risk. Patients themselves often do not know which records and formsthey will need, meaning that despite their interest in ensuring anefficient transfer, they are ill-equipped to do so.

There is no widely used standardized procedure in place to efficientlyfacilitate transfer of records between offices, meaning that aresponsible patient and cooperative, well-organized practices must bepresent to ensure each doctor is properly informed. Three-waycommunication between the patient and both practices is at bestcumbersome, and at worst ineffective in ensuring that records aretransferred completely and in timely fashion. Regional HealthInformation Organizations (RHIOs) do attempt to solve this problem byintegrating into clinical systems, defining common ontologies andstandardizing quantitative results. However, these systems are typicallylimited to institutional settings, don't filter information for what isnecessary for the referral, and thus tend to suffer from very limitedadoption. They tend to be used mostly in emergency settings where noreferral was made. Breakdowns in communication and record transfers canlead to unnecessary procedures, inappropriate medication, andsuperfluous testing that combine to create additional costs for patientsand insurance providers, all the while eroding trust in medicalproviders and causing frustration on all sides.

According to further embodiments of the invention described below, amethod and apparatus are provided which allows different practice groupsto easily make patient information available to one another.Furthermore, a referring doctor can track a patient's progress aftertreatment by a specialist, eliminating uncertainty and allowing for moreeffective treatment at their next meeting. Document loss becomes anon-issue, as digitally archived documents on the aggregator's serverscannot be lost or misplaced.

Personal patient contact and insurance plan data are stored on theaggregator's central database, and made available to pass on to areferred-to doctor. Patients' records are matched on the basis of theiremail address or phone number registered with the aggregator. Thisinformation can be transmitted automatically in conjunction with theappointment request.

Insurance forms are saved in digital form in the aggregator's database,and can be pre-filled with this data and sent in digital form to thereceiving practice in conjunction with the appointment request. Recordscan be uploaded by scanning them, or by faxing them under asystem-generated cover page to the aggregator (where in turn they aredigitized automatically and stored in the aggregator's database). Forexample, a system-generated cover page may feature a bar code, whichallows the aggregator's computers to identify the faxed record and itsintended recipient, and forward it on automatically to that location byemail. Records can also be outputted as faxes at practices where this isnecessary or preferred. These processes require no additional equipmentother than that present today in almost all medical offices, i.e., faxmachine at minimum.

Tracking the Referral Process

Further embodiments of the invention will now be described which enablea referring physician to track his historical and ongoing referralappointments. This tracking and management process solves severalrecognized problems with current methods and can enhance patient care.After a discussion of the problems this new system and method addressesand overcomes, a specific embodiment will be described with respect toFIGS. 8-10.

Reducing Patient Non-Compliance

Patient non-compliance is a major inefficiency factor in the physicianreferral process. No patient can be relied upon completely to book andattend a referred appointment. Referred appointments not kept mayendanger the patient's health, are lost revenue for the receivingdoctor, and may increase overall healthcare costs if the patient'scondition becomes worse because he did not receive timely care.

Non-compliance can also cause legal problems, as a referring physicianmay have a legal obligation to make a referral when it is deemed to benecessary. Adverse health effects following non-compliance in a systemwithout standardized documentation procedures exposes physicians topotential legal challenges—a patient or a patient's relatives may becomeconvinced that no proper referral was given, and place the onus on thephysician to prove otherwise.

The Referral Cockpit described below increases the likelihood of patientcompliance. An appointment made at the time of referral, in thereferring doctor's office, and communicated to the patient in writingand by e-mail is far more likely to lead to a successful referralappointment than current procedures, which in some cases are as basic assimply providing a patient with a list of qualified specialists andcontact information. Furthermore, making a specific appointment throughthe Referral Cockpit involves the receiving practice in the patient'scare. This practice now has the ability to contact a patient withreminders (see above), further reducing non-compliance. The ReferralCockpit's documentation functions ensure that compliance with legalreferral obligations is recorded and unquestionable.

The status of referral appointments past and scheduled can be tracked bythe referring practice using an “Appointment Status” indicator asdescribed below. A “Suggested Action” indicator provides the doctor orhis staff with one-click access to a patient's contact information,further simplifying the process of following up on referrals. Areferring practice is thus also informed immediately and automaticallyof a missed referral appointment.

Post-Referral Reporting on Patients

At present, there is no convenient procedure doctors use to follow up ona patient's progress after a referral appointment. Primary careproviders are obligated by law to follow up on patients they havereferred, but frequently are frustrated by the need to proactivelycontact other practices. In many cases, several attempts at contact mustbe made to administer a single patient, a process that createsinefficiencies and extra costs while increasing the likelihood oferrors. Patient proactivity would offer no solution in consideration ofthe fact that a layman patient, in most cases lacks a sufficientunderstanding to pass medical findings along effectively. This imperfectand haphazard state of affairs has negative implications in terms of thequality of care provided. It also hinders primary care providers fromscheduling follow-up appointments, which are important from a medicalstandpoint and also generate revenue.

The present invention provides doctors with a tool for managingcommunications on a patient-by-patient basis via the Referral Cockpit.They can see their colleagues' (referred-to physicians) findings andprepare themselves accordingly prior to their follow-up appointment witha patient. Doctors can communicate about patients throughpatient-specific channels, thus ensuring that these exchanges are notforgotten amidst other work.

Documents can be easily made available using the aggregator's databaseeither by scanning or using the fax process described earlier. TheReferral Cockpit's search interface allows for communications to befiltered on a patient-by-patient basis, allowing each doctor to see theentire history of documentation and data exchanged and offering atangible improvement over prior means of communication.

A “Booking History” search function (described below) provides a doctoran overview of referrals given. Referrals can be filtered by physician,specialty, and/or appointment date. “Appointment Status” and “SuggestedAction” functions can again be used to provide a quick overview of stepsto be taken for a specific patient, eliminating the prior need toanalyze each patient's file and follow up where necessary.

Post-Referral Reporting on Doctors

By referring patients to another physician, a doctor effectively grantsa colleague access to trust-based doctor-patient relationships that formthe core of his or her business. It is accordingly in the referringdoctor's interest, both from a professional standpoint and with a viewto his or her own reputation, to ensure that patients referred elsewherereceive care quickly and efficiently, and that they are satisfied withtheir patient experience. Without a tool to systematically trackpost-referral care, doctors rely on intuition when deciding where torefer their patients. Other than time consuming individual follow-ups toevery referral, there is little a doctor can do to gain an overview ofand assess the doctor-patient relationships being built between “his” or“her” own patients and the specialists he or she refers to.

Comprehensive reporting on referrals is a central feature of theReferral Cockpit. This allows doctors to more objectively evaluateprofessional relationships, which in turn should create benefits forpatients hoping to be referred to reliable and competent doctors.Practices deficient in sharing documents, accepting referred patients atthe time desired, or making use of information shared can be more easilyidentified.

Post-referral reporting on doctors is available via the “BookingHistory” function using the same search interface as for post-referralreporting on patients. The post-referral tracking can be sorted based onreferred-to physician.

Booking History

The embodiment illustrated in FIGS. 8-10 will now be described. FIG. 8shows a web page 130 on the aggregator's website that enables thereferring physician to track referral appointments. The page, entitled“Booking History”, includes a number of filtering windows in an upperportion 131, enabling the referring physician to filter based onselected criteria and generate a booking history report. Here, thefiltering windows include two windows 132-133 for entering a date range,a window 134 for selecting a particular patient (or leaving the window134 blank to select all patients), a window 135 for selecting a specificreferred-to physician (or leaving the window 135 blank to select allreferred-to physicians), a window 136 for filtering based on specialtyof the referred-to physician, and a window 137 for identifying acriteria for sorting the results, e.g., by patient name or referred-tophysician. By clicking the generate report button 138, the aggregator'sprocess filters the entered information and generates a report, such asthe booking history 140 shown in the lower portion of web page 130.Here, the booking history report includes a grid of rows and columns,arranged in reverse appointment date order, for a plurality of referralappointments. Across the top of window 140 there are a plurality offields (column headings) 141 which include, in serial order across thepage: appointment status 142, results 143, patient name and phone number144, referred-to physician 145, appointment date 146, appointmenthistory 147, and suggested actions 148. Ten row entries 150-159 areillustrated below, each row being specific to a particular referralappointment. For example, the first row entry 150 indicates that patientMichael Smith (field 144) was referred to physician Alexander Arkansas(field 145) for an appointment on May 24, 2010 (field 146), and that theappointment was booked on May 2, 2010 (field 147). In the first column(field 142), Michael Smith's appointment status is awaitingconfirmation. In other row entries, alternative appointment statusindicators include confirmed (row 152), rescheduled (row 153), patientcancelled (row 154), received results (rows 155 and 158), awaitingresults (row 156), practice cancelled (row 157) and patient no-show (row159). In the results column 143, an icon is displayed if results of theappointment have been stored on the aggregator's database. In the lastcolumn 148, there is a link identifying a suggested action to be taken,e.g., contact patient if the patient has either cancelled or did notshow up for the referral appointment. This prompts the referringphysician to communicate with the patient for establishing a newappointment.

If this example (FIG. 8), the row entry 155 for patient Richard Smith ishighlighted and selected by the referring physician on web page 130;this action causes a more detailed referral history for the appointmentto be displayed, as shown in FIG. 9. In FIG. 9, the web page 170 nowincludes an enlarged window 171 with a referral summary for patientRichard Smith. The referral summary includes, in serial order startingat the top of the window 171, identification of the referred-tophysician, his specialty, the reasons for the patient visit and the dateand time of the appointment 172. By clicking on the button 173, thereceived results of the appointment can be displayed. Below box 172,there is provided a link 174 for displaying the insurance referral form.Below this, there is a box 175 for displaying the attachments, namelythe files shared by the referring and referred-to physicians (threefiles are shown). For each file 176 three options (link or checkbox) areprovided enabling the referring physician to download the file 177,remove the file 178, or refax the file to the referred-to physician 179.In addition, the referring physician can click a link 180 to add anotherattachment and click button 181 to refax the selected attachments to thereferred-to physician. Below this, there is a results display 182 whichhere includes a link 183 for reviewing the EKG results of theappointment. Below this, there is an entry box 184 enabling a physicianto enter a message to the patient, and a button 185 for sending themessage to the patient. Below this, there is provided (partially shown)a similar message window 186 for entering a message to the referred-todoctor, and a button (not shown) for sending the message to thereferred-to doctor.

FIG. 10 shows a complete referral summary in window 191 on the web page190. This alternative provides a more detailed report for the selectedpatient Richard Smith and includes the same text 172 and button 173 asin FIG. 9. The referral summary provides an audit trail 194 which listsin serial order going down the window, a reverse chronological list ofevents concerning the referral appointment. Here, the illustrated eventsinclude an entry 195 that results were added to the aggregator'sdatabase by the referred-to physician 195, a message sent to thereferred-to doctor 196, a message sent to the patient with a link toshow the message 197, patient confirmation 198, and various attachmentsthat were faxed 199, 201-203 or added 200, 204 to the database.

The above embodiments illustrate select features of the invention forboth online booking and tracking of referral appointments. These samefeatures are useful in a variety of healthcare provider practices, asdescribed further below.

Facilitating Referrals to In-Network and Affiliated Physicians

Large hospitals and hospital networks often employ or maintainaffiliations with primary care providers. Ideally, these primary careproviders should refer patients for secondary or tertiary care withinthe hospital network they are affiliated with. This would ensurecontinuity of care and records, benefiting the patient, while benefitingthe hospital. Without in-network referrals, the cost of care atintegrated facilities increases. Similarly, investments that couldbenefit patients become more difficult to undertake.

By offering instant access to each specialist's calendar through theReferral Cockpit, a hospital or hospital group can provide itsphysicians with a real incentive to refer within network—speed and easeof use. Referrals within network can be made significantly more quickly,increasing the speed of care. Furthermore, search results within theReferral Cockpit can be narrowed down to just in-network doctors,offering physicians a quickly accessible view of professionals withintheir network. The Cockpit's integrated document-sharing features alsoserve to ensure continuity of care, reducing the hospital's exposure tomalpractice allegations. Finally, by adopting the Cockpit a hospital(group) can ease for its administrators the task of monitoring adoctor's use of their in-network colleagues when referring. Overall, thelikelihood of in-network referrals increases, creating benefits for thehospital while improving the quality of care for patients.

The benefits described above occur by leveraging the Referral Cockpit'sindividual functions, and applying them as an enterprise solution ratherthan an improvement to a single practice's infrastructure. Pre-selectionof in-network doctors can occur by accessing saved affiliation datastored on the aggregator's database.

Ensuring Care After Hospital Discharges

A patient's need for medical care does not typically end once dischargedfrom a hospital. Usually, a number of follow-up appointments arenecessary. The hospital is obligated to instruct the patient toundertake these if there exists a medical necessity. However, atpresent, there exists no standardized framework for ensuring that theseappointments actually occur, or that post-discharge care fulfills theobjectives envisioned by a hospital's physicians and their dischargeteams.

Using the Referral Cockpit, a hospital's administrative staff caninstantly transfer records of and book appointments for a patient aboutto be discharged. This fulfills the hospital's legal obligations anddecreases the likelihood of inadequate care after discharge.Furthermore, it does also provide integrated hospital facilities orhospitals operating within a large provider network the opportunity tokeep the patient in-network, especially in cases where a patient may nothave an existing relationship with the medical provider(s) he or she isrecommended to continue seeing.

No additional functions of the Referral Cockpit, other than thosealready described, are necessary to implement this application.

Managing Emergency Care Facility Capacity

Many hospital emergency rooms are frequently over capacity. They treat avariety of patients, ranging from those without serious ailments tolife-threatening cases. Furthermore, many patients enter the emergencyroom simply because they do not have immediate access to their preferredprimary care provider, or because they do not have a primary careprovider. While primary care capacity elsewhere goes unutilized,emergency rooms find themselves struggling to cope with a deluge ofpatients, increasing wait times for all as well as the risk of mistakesand inadequate care.

Emergency room staff working with the Referral Cockpit can identifylow-priority cases, and access a real-time view of available primarycare providers in the vicinity. This helps decrease waiting times,provides patients with faster access to care, and allows physicians andmedical staff to concentrate their efforts on those patients in thegreatest need of true emergency care. Furthermore, the Referral Cockpitcan be used to steer patients to providers within the same providernetwork as the emergency facility.

The Referral Cockpit's core functions, as described above, are allequally applicable in this scenario. The Cockpit's documentationfeatures serve to create a record of the emergency facility havingfulfilled its obligation to provide care.

Ensuring Post-Emergency Care

In 2009, the Annals of Emergency Medicine published the results of astudy showing that fully 78% of emergency care patients did not fullyunderstand the instructions given to them¹. Of all patients, 34% foundthemselves unclear about their post-emergency care. Furthermore,handwritten communication was found to be a major source of patientconfusion. Patients unclear about what to do once they leave theemergency room are at risk of eschewing needed follow-up care, causingadverse effects on their health. Their situation can degenerate to thepoint where more emergency care is required. This state of affairs isinefficient, costly and dangerous, and exacerbated even further by thefact that even comprehending patients are often found to benon-compliant, as described above. ¹ “Patient Comprehension of EmergencyDepartment Care and Instructions: Are Patients Aware of When They Do=NotUnderstand? Annals of Emergency Medicine, Vol. 53 Issue 4, April 2009.Study attached.

Emergency room staff can use the Referral Cockpit to make a confirmedappointment with a physician qualified to provide post-discharge care.Once this appointment is made, reminders can be sent to the patient inthe time leading up to the appointment, and documents transferredelectronically to the receiving physician. Each of these steps increasesthe possibility of patient compliance and efficient post-emergency care.

Emergency care facility staff can use the Referral Cockpit's bookingfunction to make appointments. The documentation functions describedabove serve to ensure that the receiving physician is well-informedbefore administering follow-up care.

EXAMPLES

FIGS. 11-16 further illustrate various embodiments of the invention asdescribed below.

FIG. 11 illustrates the following example:

Case 1—Referral Cockpit to Referral Cockpit

-   -   1. Patient visits doctor, doctor performs diagnosis and        determines need for referral;    -   2. Doctor uses PC to log in to Referral Cockpit; request        information on availability of applicable doctors;    -   3. PC sends request to aggregator server;    -   4. Server searches connected database;    -   5. Server returns requested information to PC/doctor, doctor        then uses PC to choose specialist to refer to book appointment,        and transfer patient's records electronically to aggregator        server;    -   6. Server forwards records, reservation to specialist's PC via        server/database;    -   7. Specialist uses PC to log in to Referral Cockpit and view        appointment; contacts patient to confirm appointment, give        preparatory instructions, etc.    -   8. After appointment, specialist uses PC to log into Referral        Cockpit and transfer updated records back to doctor via        aggregator server.

FIG. 12 illustrates the following example:

Case 2—Referral Cockpit to Referral Cockpit, No Time Chosen

-   -   1. Patient visits doctor, doctor performs diagnosis and        determines need for referral;    -   2. Doctor uses PC to log in to Referral Cockpit; request        information on availability of applicable doctors;    -   3. PC sends request to aggregator server;    -   4. Server searches connected database;    -   5. Server returns requested information to PC/doctor, doctor        then uses PC to choose specialist, request appointment, and        transfer patient's records electronically to aggregator server;    -   6. Server forwards records, request to specialist's PC via        server/database;    -   7. Patient and specialist communicate at a later time outside        the Referral Cockpit system (by email, phone, or personal        conversation) to find a suitable time for the appointment;    -   8. Specialist uses PC to log in to Referral Cockpit and enter        the appointment on aggregator server, which updates database and        makes updates visible to doctor;    -   9. After appointment, specialist uses PC to log into Referral        Cockpit and transfer updated records back to doctor via        aggregator server.

FIG. 13 illustrates the following example:

Case 3—Referral to Practice Outside Cockpit System That Uses PCs

-   -   1. Patient visits doctor, doctor performs diagnosis and        determines need for referral;    -   2. Doctor uses PC to log in to Referral Cockpit; request        referral to a non-connected specialist;    -   3. PC sends request to aggregator server;    -   4. Server forwards email with request to specialist via his PC,        logs it on database;    -   5. Using PC, specialist contacts patient and doctor (by        phone/email) outside system to accept request, make/confirm        appointment;    -   6. Doctor uses PC to enter reservation into database via        aggregator server; transfer patient documents (if necessary) to        specialist electronically via aggregator server and database;    -   7. After appointment, specialist uses email/fax/mail to transfer        updated records back to aggregator server, which identifies        them, updates database, and forwards to doctor.

FIG. 14 illustrates the following example:

Case 4—Referral to Practice Outside Cockpit System Not Using PCs

-   -   1. Patient visits doctor, doctor performs diagnosis and        determines need for referral;    -   2. Doctor uses PC to log in to Referral Cockpit; request        referral to a non-connected specialist;    -   3. PC sends request to aggregator server;    -   4. Server forwards reservation request to specialist outside        system via fax, logs it on database;    -   5. Specialist contacts patient and doctor (probably by phone) to        accept request and make/confirm appointment;    -   6. Doctor uses PC to enter reservation into database via        aggregator server; uploads patient information and documents to        aggregator server—sever then outputs these to specialist via        fax;    -   7. After appointment, specialist faxes updated records back to        aggregator server, which identifies them, updates database, and        forwards to doctor.

FIG. 15 illustrates the following example:

Case 5—Referral Within a Hospital System

-   -   1. Patient visits emergency room, doctor diagnoses need for        referral to specialist;    -   2. Emergency room administrator uses PC to log in to Referral        Cockpit, request information on availability to doctors;    -   3. PC sends request to aggregator server;    -   4. Server searches connected database;    -   5. Server returns requested information to ER admin. Admin        chooses in-network specialist to refer to, book appointment, and        transfer patient's records electronically to aggregator server;    -   6. Server forwards records, reservation to specialist's PC via        server/database;    -   7. Specialist uses PC to log in to Referral Cockpit and view        appointment; contacts patient to confirm appointment, give        preparatory instructions, etc.—patient later visits specialist;    -   8. After appointment, specialist uses PC to log into Referral        Cockpit and transfer updated records back to ER admin via        aggregator server.

FIG. 16 illustrates the following example:

Case 6—Paper Record Transfer Via Aggregator Server/Database

-   -   1. Doctor scans paper records, which scanner transfers to PC;    -   2. Doctor uses PC to log in to Referral Cockpit, upload scanned        records, which are then transmitted to aggregator server;    -   3. Aggregator server matches records with existing patient and        case records, updates database, creates bar-coded cover page;    -   4. Records are now forwarded directly to specialist via fax or        PC in fax or email form, and/or specialist can re-request        automated delivery or records as necessary via fax or PC at        will, and without again involving doctor. If specialist is        outside system, records he/she emails or faxes back to        aggregator server will automatically be identified using bar        code, database will be updated, and doctor sent records via        Cockpit.

Database Structures

FIG. 17 illustrates one example of a database structure for use in oneor more embodiments of the method and apparatus of the invention. Anaggregator database uses various stored tables of doctor, appointment,and user data for implementing the booking of a referral appointment. Asshown, the doctor information table 220 may include a unique physicianidentifier (ID), physician name, specialty and sub-specialtyidentifiers, photo and physician statement information. An appointmenttable 221 may include a unique appointment identifier, practiceidentifier, physician identifier, location identifier, procedureidentifier, start and end time for the procedure, a user identifier andduration. A user table 222 may include a unique user identifier, name,user key, gender and date of birth. This use of a relational database ismeant to be illustrative of just one possible embodiment and notlimiting.

FIG. 18 illustrates one example of a stored appointment table for use inone or more method or apparatus embodiments of the invention. The storedrecords of appointments in the aggregator's database may include each ofthe following fields:

-   -   ID;    -   practice ID;    -   doctor ID;    -   location ID;    -   procedure ID;    -   start time;    -   end time;    -   user ID;    -   duration.        Again, this is one example of a table of stored referral        appointment information utilizing the doctor, appointment and        patient information stored in the aggregator database and is not        meant to be limiting.

System, Method and Computer Program

As will be appreciated by one skilled in the art, the present inventionmay be embodied as an apparatus or method, including a computer systemor computer program product. Accordingly, unless specified to thecontrary, the present invention may take the form of an entirelyhardware embodiment, an entirely software embodiment (includingfirmware, resident software, micro-code, etc.) or an embodimentcombining software and hardware aspects that may all generally bereferred to herein as a “circuit,” “module” or “system.” Furthermore,the present invention may take the form of a computer program productembodied in any tangible medium of expression having computer-usableprogram code stored in the medium.

Any combination of one or more computer-usable or computer-readablemedium(s) may be utilized, unless specified to the contrary herein. Thecomputer-usable or computer-readable medium may be, for example but notlimited to, electronic, magnetic, optical, electromagnetic, infrared, orsemiconductor storage mediums. More specific examples (a non-exhaustivelist) include: a portable computer diskette, a hard disk, a randomaccess memory (RAM), a read-only memory (ROM), an erasable programmableread-only memory (EPROM or Flash memory), and a portable compact discread-only memory (CDROM), an optical storage device.

Computer program code for carrying out operations of the presentinvention may be written in any combination of one or more programminglanguages, including an object oriented programming language such asJava, Smalltalk, C++, C#, JavaScript/Ajax and similar programminglanguages. JavaScript, which relies on a runtime environment in a webbrowser, is commonly used for website development (e.g., writingfunctions that are embedded in or included from HTML pages). JavaScriptcan be used as a scripting language for implementing an Ajax-embeddedwebpage. Unless otherwise specified, the program code may executeentirely on a user's computer, partly on the user's (e.g., server orclient) computer, as a stand-alone software package, partly on a user'scomputer and partly on a remote computer or entirely on the remotecomputer or server. In the latter scenario, the remote computer may beconnected to the user's computer through any type of network, includinga local area network (LAN) or a wide area network (WAN), or theconnection may be made to an external computer (for example, through theInternet using an Internet Service Provider).

A website is a collection of web pages posted on one or more webservers, accessible via the Internet. A webpage is a document, typicallywritten in [X]HTML, that is generally accessible via HTTP, a protocolthat transfers information from a web server to a display in the user'sweb browser. The collection of publically accessible websites arereferred to as the “World Wide Web”.

Websites are written in, or dynamically converted to, HTML (hyper textmark-up language) and are accessed using a software interface known asthe user agent. Web pages can be viewed or otherwise accessed from arange of computer-based and Internet-enabled devices of various types,including desktop computers, laptop computers, PDA's and cell phones. Awebsite is posted on a computer system known as a web server, and itincludes software that retrieves and delivers the pages in response torequests from the website users.

A dynamic website presents variable information that is tailored toparticular users. It may accept the user's input and respond to a user'srequest. For example, the user can enter text into a data entry field orform or select highlighted (linked) options, which prompts the websiteto fulfill the request and return a unique result. The aggregator'swebsite, accessible in various forms to patients, hospitals, insurersand practice groups, includes such dynamic functionality.

A link or hyperlink, is a reference or navigation component in adocument to another section of the same document or to another documenton a different domain. A web browser usually displays a link in somedistinguishing way, e.g. in a different color, font or style. When theuser activates the link (e.g. by clicking on it with the mouse) thebrowser will display the target of the link.

As used herein, database and central database are not meant to belimiting, and may reside in one or more locations and/or datarepositories. The aggregator's database is referred to as a centraldatabase to distinguish it from the separate multiple databases of theunaffiliated practice groups from which the aggregator combines(aggregates) the available appointment times to be offered on theaggregator's website. Database as used herein is not meant to belimiting and may include various forms of data repositories andapplications for indexing, search, storage and retrieval of suchrepositories.

The aggregator can, by collecting and storing this available appointmentdata from a plurality of unaffiliated practice groups, provide a muchlarger database of available appointment times/specialties/proceduresand can allow patients to book appointments directly with theaggregator, without requiring the patients to contact the practice groupin any manner (by phone, email or practice group website).

The present invention is described above with reference to flowchartillustrations and/or block diagrams of methods, apparatus and computerprogram products (systems) according to embodiments of the invention. Itwill be understood that each block of the flowchart illustrations and/orblock diagrams, and combinations of blocks in the flowchartillustrations and/or block diagrams, can be implemented by computerprogram instructions. These computer program instructions may beprovided to a processor of a general purpose computer, special purposecomputer, or other programmable data processing apparatus to produce amachine, such that the instructions, which execute via the processor ofthe computer or other programmable data processing apparatus, createmeans for implementing the functions/acts specified in the flowchartand/or block diagram block or blocks.

These computer program instructions may also be stored in acomputer-readable medium that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablemedium produce an article of manufacture including instruction meanswhich implement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams illustrate the architecture,functionality, and operation of possible implementations of systems,methods and computer program products according to various embodimentsof the present invention. In this regard, each block in the flowchart orblock diagrams may represent a module, segment, or portion of code,which comprises one or more executable instructions for implementing thespecified logical function(s). It should also be noted that, in somealternative implementations, the functions noted in the block may occurout of the order noted in the figures. For example, two blocks shown insuccession may, in fact, be executed substantially concurrently, or theblocks may sometimes be executed in the reverse order, depending uponthe functionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts, or combinations of special purpose hardware andcomputer instructions.

By way of example only, various described embodiments may be implementedon processor based servers, such as any x86_(—)64 processor basedserver, for example running a Windows Operating System, e.g. WindowsServer 2003, Windows XP/Vista, including Microsoft's NET Framework (e.g.Net 2.0). The database programming may be implemented in the SQLprogramming language (e.g. MS SQL 2005 and TSQL).

Modifications can be made to the previously described embodiments of thepresent invention and without departing from the scope of the invention,the embodiments being illustrative and not restrictive.

1. An online physician referral apparatus comprising: a computerapparatus for managing and storing a central managed database ofphysician profiles and scheduling information for physicians belongingto different provider groups, the database containing both physicianprofile data (PPD) and available appointment times for the physicians,wherein the PPD includes the physician's specialty, location andinsurance or payment information; and an online portal, accessible bycomputer to referring physicians over a network, for computerimplemented filtering of the PPD and available appointment times onbehalf of a patient of the referring physician, the portal including auser interface enabling the referring physician to select and bookon-line a referral appointment on behalf of the patient with one of thephysicians based on a filtered combination of the available appointmenttimes and PPD.
 2. The apparatus of claim 1, wherein: the portalcomprises a Web site and the user interface is accessible via a Webbrowser for filtering and selecting the one physician for the referralappointment.
 3. The apparatus of claim 1, wherein: the PPD furtherincludes one or more of an affiliation of the physician with a providergroup, insurance carrier, insurance plan, and procedures performed. 4.The apparatus of claim 1, wherein: the database further includes theselected booked appointments and patient records relevant to suchappointments.
 5. The apparatus of claim 1, wherein: the databaseincludes an identifier for correlating patient and patient records.
 6. Amethod for online booking of physician referrals comprising: a referringphysician accessing an online portal to a central managed database ofphysician profile data (PPD) and available appointment times forphysicians belonging to different provider groups, the PPD including thephysician's specialty, location and insurance or payment information;the referring physician performing the following steps via the portal:filtering the PPD and available appointment times on behalf of a patientof the referring physician and selecting, on behalf of the patient, areferral appointment with one of the physicians based on a filteredcombination of the available appointment times and PPD; enteringidentification information for the patient; and booking the selectedappointment for the identified patient.
 7. The method of claim 6,wherein the PPD further includes one or more of an affiliation of thephysician with a provider group, insurance carrier, insurance plan, andprocedures performed.
 8. The method of claim 6, wherein the filteringstep is based on specialty and location and the portal displays afiltered listing of the physicians and their available appointmenttimes.
 9. The method of claim 6, wherein in response to the filtering,the portal displays a filtered listing of the physicians including theirrespective name, specialty, location, and insurance or paymentinformation.
 10. The method of claim 6, wherein the referring physicianfurther performs the step of tracking one or more selected appointments.11. The method of claim 10, wherein the tracking is performed based onone or more of the selected physician and the patient.
 12. The method ofclaim 6, further comprising the step of the referring physiciantransferring patient information to the selected physician.
 13. Themethod of claim 6, further comprising the step of the selected physiciantransferring patient information via the portal to the referringphysician.
 14. The method of claim 6, further comprising the step of thereferring physician reviewing on the portal a booking history ofselected appointments.
 15. The method of claim 14, wherein the bookinghistory can be filtered by the referring physician based upon one ormore of the patient, selected physician, specialty and date.
 16. Themethod of claim 14, wherein the booking history comprises one or moreof: appointment status; clinical information; patient identificationinformation; selected physician; appointment time; appointment history;and further actions regarding the patient.
 17. The method of claim 6,further comprising the step of the referring physician establishingcommunication via the portal with one or more of the patient and theselected physician.
 18. The method of claim 17, wherein thecommunications include one or more of a reminder to the patient andproviding patient information to the selected physician.
 19. The methodof claim 17, further comprising the step of the referring physicianreviewing a history of the communications on the portal.
 20. The methodof claim 6, further comprising the steps of the portal displaying adescription of the booked appointment and the referring physicianprinting the displayed description and providing the printed descriptionto the patient.
 21. The method of claim 6, wherein the portal is awebsite.
 22. The method of claim 6, wherein patient information can beuploaded by the referring physician to the portal.
 23. The method ofclaim 6, wherein the patient information can be uploaded by the selectedphysician to the portal.
 24. A computer readable storage medium withinstructions to one or a plurality of computers for execution of themethod of claim
 6. 25. A method for online booking of physicianreferrals comprising: a referring physician accessing an online portalto a central managed database of physician profile data (PPD) andavailable appointment times for physicians belonging to differentprovider groups, the PPD including the physician's specialty, locationand insurance or payment information; the referring physician performingthe following steps via the portal: filtering the PPD on behalf of apatient of the referring physician to select, on behalf of the patient,one of the physicians based on the PPD; entering identificationinformation for the patient; and notifying the selected physicianelectronically to arrange for a referral appointment.
 26. The method ofclaim 25 wherein, following the notification, the referring physiciantransfers patient information to the selected physician via the portal.27. The method of claim 25, further comprising the step of the referringphysician tracking one or more of the appointment and the patient'sprogress via the portal.
 28. A system for managing patient referralscomprising: an online portal, accessible by computer to a referringphysician over a network, providing access to a central managed databaseof physician profile data (PPD) and available appointment times forphysicians belonging to different provider groups; the portal includinga user interface enabling the referring physician to filter the PPD andavailable appointment times and select, on behalf of a patient of thereferring physician one of the physicians for a referral appointment;the portal providing one or more communication channels forcommunication between the referring physician and one or more of thepatient and the selected physician for: initiating and tracking towardcompletion the referral appointment of the patient with the selectedphysician; and transferring of patient information.
 29. A network basedscheduling system, the system comprising: an aggregator managed databasecontaining information relevant to referring physicians who periodicallyneed to schedule referral appointments with other physicians; a set ofparameters associated with each of a plurality of physicians acceptingreferral appointments having available appointment times; a centralcontroller managing a referral appointment schedule for the aggregator,wherein the central controller operates via a network to: receivescheduling information via the network from the physicians acceptingreferral appointments; supply available appointment times via thenetwork to the referring physicians, with the supplied availableappointment times determined by input received from the referringphysician on behalf of a patient of the referring physician; wherein thecontroller supplies an available appointment calendar via the network tothe referring physician of the available appointment times, and whereinthe referring physician can schedule an appointment via the network byselecting a desired appointment time.
 30. The system of claim 29,wherein the network is the Internet.
 31. The system of claim 29, whereinthe aggregator provides a Web portal accessible to the physicians forreceiving and supplying the scheduling and appointment times.
 32. Thesystem of claim 29, wherein the controller synchronizes the availableappointment times with the appointment calendars of the physiciansaccepting referral appointments.
 33. The system of claim 29, wherein thecontroller supplies a real time master schedule via the network.
 34. Thesystem of claim 29, wherein the controller operates via the network tosupply tracking information relevant to the selected appointment. 35.The system of claim 34, wherein the tracking information includes one ormore of: patient contact information; patient insurance information;affiliation of the physician accepting referral appointments; patientinformation supplied by the physician accepting referral appointments;patient information supplied by the referral physician; patient clinicalinformation; appointment history information; physician notes concerningthe patient